The World Wide Web Consortium (W3C) has defined a Web service as a software system designed to support interoperable Machine to Machine interaction over a network. Web services are frequently just application programming interfaces (API) that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services. Examples of Web services include e.g. a booking service for air tickets provided by a travel agency over the Internet, a call set-up service for setting up a HSDPA (High-Speed Downlink Packet Access) connection provided by a 3G operator, and a service for setting up a multimedia session between two end users.
A number of different protocols and formats has been developed to manage Web services.
UDDI (Universal Description, Discovery, and Integration) is a protocol for publishing and discovering metadata about Web services. A UDDI server acts as a service broker for Web services. Service providers can register information about their services in the UDDI server and service requesters can contact the UDDI server to find a suitable service based on the information stored in the UDDI server.
WSDL (Web Services Description Language) is an XML (extensible Markup Language) format that is used for describing a Web service to be provided. A service requester may for instance receive a WSDL-file from a UDDI server or from a service provider as the result of a service request. The WSDL-file will explain the details that the service requester needs to know in order to use the Web service.
SOAP (Simple Object Access Protocol) is an XML-based message envelope format that can be used for communication between e.g. a service provider and a service requester.
A service provider who has implemented a service for open use by others can post information about the service on a UDDI server. This means that information on the service is stored in the UDDI server and searchable when a service requester contacts the UDDI server in the search for a desired service. If one or several suitable services are found when the UDDI server receives a service request it can respond e.g. by sending the address of the service provider of each suitable service, or a WSDL-file or URL (Uniform Resource Locator) associated with each service, to the service requester.
The information that is stored in the UDDI server about a service will generally include such data as the name of the company that provides the service, the type of the service and information required for connecting to the service (e.g. a URL). The information may also include QoS information such as the capacity of the Web service, i.e. the number of simultaneous requests that can be supported, information on robustness of the Web service and information relating to the performance of the Web service. The W3C document “QoS for Web Services: Requirements and Possible Approaches” http://www.w3c.or.kr/kr-office/TR/2003/ws-qos/ describes QoS requirements for web services.
The US patent application US 2005/0235053 discloses a method and mechanisms for searching for Web services that makes it possible for a service requester to receive a list of possible services along with information on the service history of each service. The service requester can then select a service from the list based on the received information. For this purpose the service provider will collect information regarding the delivered quality of service in the past, i.e. the service history resulting from actual operation of the service and provide this information to the UDDI site.
However from the point of view of the service requester the prior art mechanisms for searching for Web services have drawbacks since they are not particularly focused on the interests and needs of the service requester. A service requester may have special QoS requirements for a certain service. But with the Web service solutions that are available today it is difficult for the service requester to find a Web service that fulfils his/her requirements. For example, a service requester may want to use a Web service to set up a multimedia session between two end users. The requester has certain QoS requirements for the session such as transmission rate, packet loss, transmission delay and jitter delay. With the Web service solutions that are described in the above mentioned W3C document and US patent application the service requester may be able to receive some information either relating to the capacity of a web service in general or information relating to the QoS that the service has been able to provide in the past, but this will not give the requester any information on the QoS that the requester will receive for his/her session. The capacity of a Web service is changing dynamically depending on the number of currently ongoing sessions and their QoS requirements. The service that historically has provided the best QoS may not be the best choice for the requester at the time he/she wishes to set up the multimedia session due to a very large number of ongoing sessions at that time. If there are several service providers, the service requester wants to get the service from the service provider who can best satisfy his/her QoS requirements. The service requester will probably not be interested in general QoS requirements such as the number of simultaneous requests that can be supported. He/she will mainly be interested in what the best quality of service is that he/she can get for the moment from the service provider.